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(54) System for conte3rt-<lependent name resolution 



(57) A context-dependent, multiply binding name 
resolution system. A nanrie resolver Is provided, con- 
nected to either a requester's system or a receiver's sys- 
tem, or both. Requests to a given service or domain 
name are resolved to the appropriate IP address. The 
intended recipient of the request is resolved based upon 
a combination of one or more predetermined criteria, in- 
cluding: infomiation about the sender (e.g. geographical 



location, specific requester identity, etc.); anformation 
about the intended recipient (e.g. load balance al the 
receiver, type of service, etc.); information obtained 
within the request itself (e.g. type of sennce requested); 
or other information (time of day, date, random selection 
of recipient, e.g.). The system is Implemented in hard- 
ware and/or software, and the resolutlori criteria can be 
made interdependent or independent. 
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Description 

This invention relates to systems for context-de- 
pendent name resolution. 

In a network (either Intranet or Internet) system, 
when a host wants to communicate with another host or 
locate a sen^ice or another host on the network, the ad- 
dress is typically resolved in an absolute manner; that 
is, the naming service ot the network resolves a given 
name to a single IP (Internet Protocol) address. For in- 
starjce, a domain name service (DNS) call resolves a 
name to a single IP address or host name on the Inter- 
net] 

When there are many connections to a given host 
or se wice, the resulting congestion degrades the overall 
portormance. The service provkler may upgrade the 
senJice, e.g. to increase its capacity. In this case, in or- 
der' to keep the nrKxJification of the sen/ice transparent 
to rfequesting hosts, a demultiplexer nr«y be used, as 
illustrated by way ot example in Figures 1-2. For in- 
stance, in Figure 1 a call to Sen/rce 3 will be unk^uely 
resolved to that sendee's IP address and transmitted 
there accordingly, because there is only a single binding 
in the DNS name resotver to the host ot Servce 3, In 
general, in a conventwnal system such as that illustrat- 
ed in Figures 1 , 2 and 2A, there will be a single binding 
between a name and an IP address. 

Yet another alternative is for a specal type of de- 
muKiplexer. whrch may nrKjnitor the traffic, and from the 
different IP addresses can collect statistics such as re- 
sponse time and/or the toad on the corresponding IP 
hosts, and use this informatwn for toad balancing by 
binding a requested name to an IP address for a host 
which is less heavily loaded. 

If Service 3 is upgraded to Include Services 3.1 
through 3.Y. then the demultiplexer is added (see Figure 
2); the requesting or DNS resolving host resolves the 
request as usual and sends it out over the (Inter- or In- 
tra-)network. but the demultiplexer is interposed be- 
tween the network and the sen^ice(s). to route the in- 
coming requests to one of the services. Note that in this 
case, there is still a single binding between the DNS and 
the demultiplexer. 

A problem with this approach is that the demulti- 
plexer acts as a limiting factor on throughput, and addi- 
tionally represents a single source of failure for all of the 
sen/ices that it senses. A mechanism is needed whereby 
such a critical point and bottleneck can be avoided, 
while still providing access to the services for remote 
users. 

An alternative approach to decreasing congestion 
is through DNS spoofing, where the name resolver is 
fooled into giving out a different name binding, by keep- 
ing the name resolver updated frequently with a new 
name resolution binding based on some criteria such as 
load distribution on target servers. An example of DNS 
spoofing is shown in Figure 2A. in which a requester 2 
issues a request using the name "sun.com", and a DNS 



lookup 4 tooks it up. The host (1 . 2 or 3) to which the 
names Is bound will depend upon criteria emptoyed at 
the destination domain, as detennined by DNS spoofing 
sendee 6. Such criteria may include toad on the hosts, 
s their availability, etc. The DNS spoofing sewice 6 polls 
the hosts 1-3 perkxiically or at demand, and binds one 
of them at a time to the DNS lookup name resolver for 
the name 'sun.comV 

In a spoofing sen^ice, the criteria used to achieve 
to the binding are not related to the context of the request- 
er; they rely only upon infornriation at the destinaton. 
Thus, much inf omrtatton that could be important in mak- 
ing a binding is not utilized. In none of the known sys- 
tems is caller context used. 
16 It wouto accordingly be advantageous to have a 
system which takes into account the context of the re- 
quester in the process of name resolutkxi. 

Vartous respective aspects and features of the in- 
vention are defined in the appended claims. 
20 A context-dependent name resolution system is 
presented, which implements predetermined criteria for 
static or dynamic binding of a "name" to any one of sev- 
eral "objects" of the same type. Which 'object" is select- 
ed for the binding is determined by a 'name resolver" 
25 using context infornnation that is explicitly specified by 
the requestor In a name resolution tookup call to the 
•name resolver". The "name resolver", whteh is imple- 
mented as a sender program, stores a tookup table com- 
prising bindings of a "name" to several different ristanc- 
30 es Of an object, along with "policy" information which de- 
fines the criteria for selecting an instance of the object. 
For instance, the name may be an internet URL of the 
form "www.sun.com". and the resolved to object may be 
an IP address of the type 192. 146.85 .82. Thus the 
35 "name resolver* will store the tuple: <www.sun.com> 
<IP_address_1> <IP_address^2>..., and will store pol- 
icies on which IP address to bind to www.sun.com when 
a lookup request specifying "www.sun.com" is received 
by it. 

40 By enabling multiple binding support in the "name 
resolver", several advantages are realized. First, the 
system enables new resources to be added transpar- 
ently to the caller. When a new sender is added to dis- 
tribute the toad for one or more hosts corresponding to 
45 the name "sun.com", for instance, the IP address for the 
new sender is sinnply added to the tuple in the name re- 
solver. along with any desired policy criteria, e.g. to use 
only between 9 a.m. and 5 p.m. 

Secondly, the fundamental limit to scaling which is 
50 inherent in today's single binding systems is removed, 
by enabling multiple destinatton servers provkling the 
same service to be referenced by the same "name" han- 
dle by the caller (for example "sun.com"). and the name 
to be resolved by the name resolver to different physical 
55 computers sen/ers, depending upon caller context. 
Many instances of the name resolver may be running 
on different physical computers, and many instances of 
the services may be running, and the requester will ac- 
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cess the name resolver closest to him; and the resolved 
object that is closest to the requester or that can best 
serve the request (based upon some selected or prede- 
termined criteria) will be bound to the request, all trans- 
parently to the requester. Another advantage o1 the sys- 
tem of the invention is that it allows resources to be eas- 
ily replicated transparently to the user, eliminating any 
single point of failure in the network or at the sen/ice end 
point. It one valid destination fails, is not responding or 
is overloaded, the name resolver Is already capable of 
binding a "name" to multiple destinations, and the una- 
vailable destination can be disabled in the rwne resolv- 
er's internal tables, using administrative means. 

The context that may be used as a basis for the 
binding is variable; it may Irtclude information about the 
requester (e g. requester IP address, donrain name or 
inferred geographical region), about the destination 
(with similar alternatives), about the request itself (e.g. 
type or quality of service requested), or about independ- 
ent infomnation (e.g. time of day or time zone of the point 
of origin of the request). 

The system may be implemented (eg as part of a 
computer apparatus) using hardware, software, or com- 
binations thereof . 

The invention will now be described by way of ex- 
ample with reference to the accompanying drawffigs, 
throughout which like parts are referred to by like refer- 
ences, and in which: 

Figures 1 -2A are diagrams of present network sys- 
tems used for destination addresses for requests. 

Figure 3 is a flowchart illustrating a method accord- 
ing to an embodiment of the present invention. 

Figures 4 and 5 are diagranns of network systems 
incorporating features of embodiments of the present in- 
vention. 

Figure 6 in an illustration of the operation of an em- 
bodiment of the invention using geography-based res- 
olution criteria. 

Figure 7 is a diagram depicting zones in which do- 
main name servce resolvers and servce locatkxi re- 
sotvers of the invention may be located, 

A method according to the invention is illustrated in 
Figure 3, and Figures 4-5 shows a suitable systenre im- 
plementable on the Internet or Worldwide Web, the In- 
ternet or an Intranet., incorporating features of the name 
resolution system. 

Name resolution can include any kind of name res- 
olution lookup for binding one object to another. This in- 
cludes binding the name of a service to a host computer 
(or its IP address) that provides that service, and binding 
the type of sen/ice to the name of a service providing 
that type of sen/ice. It also includes resolving a name in 
one domain to another name in the same domain, and 
to another name in a different domain. For the purposes 
of this invention, the terms "service* and 'hosf can be 
considered synonymous, as can "sen/ice location* and 
'host locationV 

The system includes three fundamental features 



that can be implemented singly or in any combirtation 
with one another: multiple bindhg of destination ad- 
dresses to names; caller context name resolution incon- 
nectlon with such multiple binding; and name resolution 
5 policy considerations, i.e. independent criteria upon 
which such resolution is based. 



Name Resolution : An Example 

10 An example of name resolution occurs, for instance, 
when a user wishes to view vkieo, e.g.a movie, on his 
or her computer. An applicatkin running on the computer 
is used to nr«ke a procedure call to the name resolver 
to determine whteh server can sen^e a nrKwie. e.g. 
IB sen^ice_handle = nanr>e_service_kx)kup("movie*) 
where the string "movie* is passed Jo a sen/er. whk:h 
then returns the name of the seryce provkJing that nrrov- 
ie (or it may return a linked list of sewices providing mov- 
ie sen/fces, from whteh the user may t>e prompted to 
20 select one). 

The server nnay, by way of example, return a single 
service nanoe (e.g. "quickttme") m the variable called 
'sen/ice_handle". Next, the applk»tk>n nrujst detemnffie 
which sen/er host can provkle this service to this client; 
2S to do this, it makes another narrw resolutkxi call: 

host_handle = name_hoslname_idokup 
(servk;e_handle) 

and passes it the variable "servce^handle' returned by 
the prevk>us call. This call returns it the name of a sen/er 
30 which is listed as offering this sen^fce. 

The network kx^aton this server must now be de- 
termined, so that the user's computer or workstation can 
connect to it to get the movie servce, and so it . makes 
the call: 

35 host_IP_address = nome_hostaddressJookup 
(h06t_handle) 

and finally obtains an IP address of an appropriate host 
that can provide the movie service to the user. 

Further calls to this quicktinrw sewer may determine 
40 a list of nwvies that are available. Altematively, a design 
may be had in which the caller simply specifies the name 
of the movie he wants to see, and the name kx>kup re- 
turns to the caller the IP address of a host that is cur- 
rently able to serve the requested movie to the caller 
4$ All of or some of the above steps may be combined 
in more integrated calls to the nanne resolver. 

In the present invention, in additkxi to the above, 
an additional parameter is passed to the 
name_hostaddress„lookup() function above (or to all 
50 the functions above); this parameter rnay be called the 
caller.context. This caller_context is used by the nanne 
resolver to help it decide v^^ich IP address to use. Thus, 
the calls would look like: 

host_IP_address = name„hostaddressjookup 
55 (host_handle, caller_context). Caller_context is a cook- 
ie (or stoicture) that may include informatton such as the 
caller's IP address, its point of origin, the quality of the 
requested service, or any other context that might be 
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relevant. These contexts must be well specified and 
their format(s) standardized, so that many ditlerent 
name resoh/ers can interoperate properly. The particu- 
lar caller.context formats and contents selected are not 
themselves crucial, 

The present embodiment uses requester context- 
dependent intelligence to determine which of several 
destination hosts should be utilized, or in other words, 
which of several IP addresses should be used to resolve 
a given "name" request. The context-dependent intelli- 
gence, implemented as hardware or software or a com- 
bination of both, allows the "name" resolution to be 
based upon some context information from the reques- 
tor, and/or upon the "name" being resolved in a context- 
free manner, but optionally dependent upon criteria 
such as load balancing on the destination. 

As shown in Figure 4. a requesters 100-120. of 
which there may be an arbitrary number, each comprise 
computers or workstations on a local network, served 
by a server 1 50. The requesters will typically be conven- 
tional workstations, personal computers, or any net- 
workable computing device, with local processors (1 30. 
etc.), memory (140, etc.). mass storage (not shown) and 
network connections. The server 150 also includes a 
conventional processor 160. memory 170. mass stor- 
age and necessary connections and control hardware 
and software. 

A name resolver 180 fonms part of the server 150. 
or may be a separate unit. It may be implemented en- 
tirely in software, i.e. as prograrn modules stored in 
mass storage and/or the memory 170, or it may be a 
stand-alone device, with its own logic or processor and 
memory, as desired. 

The server 150 is connected to a broader network 
170, suchas thelnlernet. an Intranet or WAN (wide-area 
network), orthe Worldwide Web. via a network connec- 
tion (e.g. a T-line) 260. On this network 170 is optionally 
another name resolver 200, which may be implemented 
in the same fash ton or differently from the name resolver 
180. Name resolvers 180 and 200 may both be used, or 
either may be used by itself. (See discusston of Figure 
7, below.) 

Destination hosts 21 0-230 may also be convention- 
al computers or workstations with processors (such as 
240), memory (such as 250), mass storage (not shown), 
network connections, etc.. as needed to implement con- 
ventional network functions in addition to the features of 
the present invention. 

Referring to the flow chart of Figure 3, when a re- 
quester (such as 100-120) sends a name resolution re- 
quest to a name resolver 1 60, instead of the single bind- 
ing ot conventional systems, the name resolver 180 in- 
cludes multiple binding tables and/or functions (imple- 
mented by appropriate logic or program modules) to re- 
solve the request to an appropriate I P address for a des- 
tination host (such as 210-230 in Figure 4). 

An example of such a multiple binding would be the 
binding of multiple, geographically disparate destina- 



tions to a single domain name. If, for instance, a user in 
Germany wishes to access www.sun.com (the WWW 
sender for Sun Microsystems, Inc.), he or she can simply 
use the Uniform Resource Locator (URL) 'http*7/www. 
5 sun.com"). Thus, the user sends the request trom re- 
quester 310 (see Figure 6), and the name resolver 320 
determines that the requester is in Gennany. (See step 
20 in Figure 3). The selected destinatton rhay either be 
in the United States or elsewhere in Europe, since Sun 
10 Microsystems in this example has two "sun.com" toca- 
tions. Since there is a valid European local destination 
330, the name resolver 320 resolves the destination ad- 
dress to sun.com (Europe), as indicated al box 30 of 
Figure 3. This resolved destination is then selected for 
15 the request packet(s) (box 40 of Figure 3), and the re- 
quest is fonwarded to sun.com (Europe) (box 50 of Fjg- 
ure 3). 

Following are lists of context-dependent resolution 
criteria applicable to the invention and usable at box 30 
20 of Figure 3. where resolutton may be based upon re- 
quester inlormation^ destination infonnnatiqn. request 
contents, or other information: 



A Resolution Based Upon Requester frrformation 

Examples ot manners in which the r^ution de- 
pendent upon requester infonr^ation may be carried out 

include: 

1 . resolution based upon the domaffi name of the 
sender, 

2- resolution based upon the inferred (tooked-up) 
actual geographic region erf the sender; 
3. resolution based upon other geography-felated 
information of the sender: 

4. either directly ascertainable trom the request 
(city/country info, e.g.); and/or 

5. indirectly ascertainable (area code, address. 

etc.); 

6. resolution based upon quality ot sen/ice desired 
by the requester; and 

7. resolution based upon requester's time of day or 
time zone. 

B. Resolution Based Upon Destination Infofwation 



Examples of manners in which the resolution de- 
50 pendent upon a specified or intended destination or re- 
ceiver infonnatlon may be carried out include: 

1 . resolution based upon the load at the receiver; 

2. resolution based upon the inferred (k)oked-up) 
55 actual geographic regk>n of the receiver; 

3. resolution based upon other geography-related 
information of the receiver: 
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4. either directly ascertainable from the request 
(city/country info, o.g.); and/or 

5. indirectly ascertainable (area code, address, 
etc.). 

Criterion B.1 can be resolved either based upon in- 
formation as perceived at the sender end or based upon 
information as it exists at the receiver end, and resolved 
at the sender end. For example, the sender might fre- 
queritly send requests to a particular server, sendee, ge- 
ographical region or organization. In this case. It may be 
advantageous to regularly poll one or more often-used 
destinations to determine their level(s) of activity. Alter- 
natively, such polling could automatically be carried out 
for any destinations for which the sender determines 
that its number of requests exceeds a certain threshold, 
or for a top predetermined percentage of requests sent 
by the requester (e.g. all destinations for which the 
nurnber of requests exceeds N1%, or the top N2 desti- 
nations to which the sender makes requests, where N1 
and N2 are appropriate predetermined numbers). Poll- 
ing can be implemented as program modules integral to 
the name resotver(s), either entirely in one or in more 
than one location (e.g. partially in a local name resolver 
and partially in the destination server). 

Alternatively or in addition, criterbn B.1 may be 
based upon infomnation at the receive end at the time 
of sending the request, and resolved at the receiver. 

C. Resolution Based Upon Request Contents 

1 . type of sen/ice requested; 

2. specific information (or type of information) re- 
quested; 

3. any other implicit information inferred from the re- 
quest; and/or 

4. any other explicit information obtained from the 
request. 

O. Resolution Dependent Upon Other Factors 

1. randomly generated selection of destination 
based upon qualified list; and/or 

2. other independently developed information. 

These resolution criteria can be used singly or in 
any desired combination with one another, as specified 
by the requester or the administrator of the destination 
(e.g. server owner or sen/ice provider). For instance, in 
the example of Figure 6 the resolution o1 the destination 
address to sun.com (Europe) could be modified rt the 
load of sun.com (Europe) is larger by some predeter- 
mined threshold amount than the load at sun.com (USA) 
" in which case the sun.com (USA) resolution could 
override the default sun.com (Europe) resolution for re- 
questers in Europe, either at all times or only during 
peak European hours, which correspond to off-peak 
hours in the United States. 



An extension of this system is in the resolution of 
services provided at the receiver network of a request. 
For instance, a given organization may have many da- 
tabase servers, and request for access to given infor- 
5 mation may in conventional systems be routed to the 
same server, because of the single binding nature of 
destinatbn resolutron. With multiple address resolution 
binding, multiple database senders (or other destinatkDn 
hosts) such as 210, 270. 280, etc. (see Figure 5) may 
JO be made available under a single r>ame. in which case 
a local service resolution sender, such as server 300 in 
Figure 5. is provided. The server 300 includes tables, 
program modules or the like as desired to resolve a re- 
quest to any one of several to many IP addresses. The 
15 selection of a given server to receive a request can de- 
pend upon, for example, load at each of the sen/ers. 

In general, the resolutcn systems or subsystems 
will be in one of three "zones" (see Figure 7): the send- 
er's zone 1 (up to, e.g., the sender's firewall or Intemet 
20 server); the name resolver system's zone 2 (which may 
be at a sen/er on the Internet, or any place outside zone 
1 which is not in the receiver's system; and the receiver's 
zone 3- Service location name resolvers may be in any 
of zones 1-3; typically, destination lookup name resolv- 
es ers. which may comprise multiple-binding domain name 
services (DNS's). will be in either zone 1 or zone 2. It 
will be understood that zones, tor the purpose of this 
appricatk>n, are administrative boundaries, and need 
not correlate to actual network boundaries. 
30 The present embodiment can interact with existing 
systems in a nurrtDer of ways. For instance, in secure 
systems where the source address is stripped from the 
request by a firewall (and only, e.g., the donr^ln name 
remains), then the entire source address would not be 
35 used to resolve the destination; the name resolver is 
provided with the program instructions or circuitry to im- 
plement this. Note also that the DNS name resolution 
may be a distinct operation from sen/ice location, and 
thus the destination can be selected due to a combina- 
40 tion of considerations including source address, re- 
quested destinatton address, and request contents, in- 
cluding the type of request made or seo^tee requested. 
The multiple binding feature of the invention allows 
a single name, Internet address (e.g. URL address such 
4S as http;//www.sun.com) or the like to represent as many 
actual senders (or sen/ices) as desired. This has a dis- 
tinct advantage of allowing nxxJificatlons, upgrades or 
replications to be made to the destination server(s) with- 
out modification of the destination address or sen/ice 
so name as used by the requester. Such modifk^atlons may 
include adding sen/ers or servces, or establishing a mir- 
ror site at a location geographically near a large source 
of requests, etc. 

There may be security and consistency implications 
55 of multiple bindings, with concomitant solutions. If a des- 
tination address can be multiply bound, a name resolver 
may be configured to bind to an incorrect address, either 
deliberately or otherwise. While this nnay also be a prob- 
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lem with existing single binding, multiple binding may 
complicate detection ot the problem. Thus, the system 
of the invention may be combined with programs and 
tables for verification that a given binding is valid. Very 
secure systems may wish to limit their multiple binding 
to a predelennined, fixed number of resolution possibil- 
ities, or even maintain the current system of single bind- 
ing as far as Internet or Web transmission is concerned, 
and implement multiple binding only behind a firewall. 
Alternatively or in addition, encryption and digital signa- 
tures may be used to ensure validity o1 bindings, and of 
modifications or additions to the bindings. 

Variations may be had by designating a given name 
resolution as a default resolution, and utilizing alterna- 
tive resolutions only upon the request meeting prede- 
temiined criteria (such as load imbalance, geographical 
distance, specific sources of the request, etc.). 

Additional bindings (i.e. additional addresses to 
which a request may resolve) may be added without the 
requester being aware of it. and indeed substitutions 
may be made at any time, again transparently to the re- 
quester. 

F. Service Selection Based Upon Caller Context 

The system of the invention may be applied more 
generally to the use of caller context tor name resolution. 
Context about the requesting user (e.g. in ^ variable 
called 'caller.context') can be passed to appropriate 
functions, such as: 

sennce.handle = name_service_lookupCmovie^. 

cal!er_context) 

host_handle = name_hostnameJookup 
(service^handle, caller_context) 
Here, the function service.handle executes a sen^ice 
name lookup based upon the input "movie", as well as 
the information in the variable caller_context, outputting 
the value sen/ice_hand!e. Given this output as input, 
along with (again) caller_context. the function 
host_handle then returns an appropriate host name. 

An example of a possible such situation could result 
when a user desires an encryption sen/ice, and several 
encryption policies are available. The service.handle 
function can be configured to return different encryption 
algorithm sen/ices based upon the specified destination 
(which is specified in caller_context), or there may be 
an effective override in the caller_context by which the 
user can select a higher level of security. 

In general, as noted above, the invention may be 
implemented at the sender's system or at the destina- 
tion system, or indeed at points in between (e.g. at proxy 
sen/ers). Note that single points ot failure and bottle- 
necks are removed using the present system, and a truly 
distributed, multiply binding name resolution system is 
achieved. 

Particular and preferred aspects of the invention are 
set out in the accompanying independent and depend- 
ent claims. Features of the dependent claims may be 



combined with those of the independent claims as ap- 
propriate and in combinations other than those explicitly 
set out in the claims. 

Claims 

1 . A system for name resolution ot at least one request 
directed to a destination name ot a receiver arid is- 
10 sued from a requester system, including: 

a name resolver connected to the requester 
sen/ice and including 

predetermined informatkxi correlating a plural- 
is ity of destination addresses with said destina- 

tion name; 

a criteria selection subsystem configufod to* 
provide a selection of at least one said destina- 
tion address based upon at least one predeter- 
20 mined criterion; and 

a destination address binder configured to bind 
said destination name with said selected desti- 
nation address 

25 2. The system of claim 1 , wherein said at least oto 
predetermined criterion includes a criterion based 
upon information explicitly contained within said re- 
quest. 

30 3. The system pt claim 2, wherein said irifonmation in- 
cludes an address of said requester. 

4. The system of claim 2, wherein said inlomr^ation is 
based upon at least a portion o1 contents d said 

35 request. 

5. The system of claim 4, wherein said portwn of said 
contents includes at least orie of: 

40 a type of service requested by said request; and 

a quality of sen/ice requested by said request. 

6. The system ot claim 1 . whereffi said at least one 
predetermined criterion includes a criterion based 

45 upon infomriation not explicitly contained within said 
request. 

7. The system of claim 6, wherein said infomnation 
pertains to a geographical region ot said requester. 

50 

8. The system of claim 6, wherein said information 
pertains to a geographical region of said receiver 

9. The system of claim 6. wherein saW informalton in- 
55 eludes toad information relating to said receiver. 

10. The system of claim 6, wherein said informatton in- 
cludes at least one of time and date information. 
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11. The system o1 claim 1 , wherein said binding is to a 
port at said destination address. 

12. The system of claim 1. wherein said binding is 
based at least in part upon a random selection of 
one said destination address. 

13. A method for context-dependent binding of a desti- 
nation name to a destination address in a name re- 
eolver having a predetermined set of binding criteria 
4nd predetermined correlations of destination 
names with destination addresses, wherein at least 
^ne said correlation is a multiple correlation corre- 
lating a plurality of said destination addresses with 
a single destination name, including the steps of: 

} (1 ) receiving said request at said name resolv- 
er; and 

(2) based upon said multiple corelation, re- 
M trieving at least one said destination address 
from said plurality of destination addresses. 



10 
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20 



14. The method of claim 1 3, further including after step 
. 2, the step of : 

(3) binding said retrieved destination address 
to said destination name. 



16. The method of claim 14. further including after stop 
3. the step of: 

(4) transmitting said request with said desti- 
nation address. 



30 



16. The method of claim 13, wherein said multiple cor- 
relation is based upon inforrriation explicitly con- 
tained within said request. 

17. The system of claim 13, wherein said multiple cor- 
relation is based upon at least a portion of contents 
of said request. 

18. The system of claim 13. wherein said multiple cor- 
relation is based upon at least one of: 

an address of said requester; and 

a type of sen^ice requested by said request; and 

a quality of sen^ice requested by said request. 

19. The system of claim 1 , wherein said multiple corre- 
lation is based upon intormation not explicitly con- 
tained within said request. 

20. The system of claim 19, wherein said multiple cor- 
relation is based upon at least one of: 

a geographical region of said receiver; 
load information relating to said receiver; 
time information; 
date information; and 



a random factor generated by said name re- 
solver. 

21 . A system for name resolution of at least one request 
directed to a destination name of a receiver and is- 
sued from a requester system, the request informa- 
tion relating to caller context, the system including: 
a name resolver connected to the requester 
service and including 

predetermined information correlatbig a plural- 
ity oi sen/ice names with said caller context; 
a sen/ice selection subsystem configured to 
provide a selection of at least one said sen^ice 
name based upon said caller context; arKJ 
a host name selection sutJsystem configured to 
return a host name based corresponding to 
said selected service name. 

22. Hie system of claim 1, wherein said at least one 
predetermined criterion includes; 

a first criterion based upon information explic- 
itly contained within said request; and 
a second criterion based upon information not 
explicitly contained within said request. 

23. The system of claim 22, wherein said second crite- 
rion con-esponds to a predetermined policy used by 
said name resolver. 

24. The system of claim 23, wherein said first criterion 
corresponds to information relating specifically to 
said requester system. 
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Figure 6 
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